Myon recently posted a nice statistic about popular single letter package name prefixes. Just out of curiosity I started wondering about popular single letter package name suffixes: On a machine with Debian oldstable, stable, testing, unstable and experimental in its sources.list, I ran the following command:

$ apt-cache search -n .   \
    awk ' print $1 '   \
    sed -e 's/.$//'   \
    sort   \
    uniq -c   \
    sort -n

And to my surprise there is a non-obvious winner:

$ apt-cache search -n '^gp.$'
gpa - GNU Privacy Assistant
gpc - The GNU Pascal compiler
gpe - The G Palmtop Environment (GPE) metapackage
gpm - General Purpose Mouse interface
gpp - a general-purpose preprocessor with customizable syntax
gpr - GUI for lpr: print files and configure printer-specific options
gps - Graphical Process Statistics using GTK+
gpt - G-Portugol is a portuguese structured programming language
gpw - Trigraph Password Generator

But since I searched through the binary packages many other hits are more obvious, like the seven packages hbf-cns40-1 to hbf-cns40-7:

      [...]
      4 ar
      4 aspell-f
      4 automake1.
      4 cpp-4.
      4 e
      4 g++-4.
      4 gappletviewer-4.
      4 gcc-4.
      4 gcj-4.
      4 gcompris-sound-e
      4 gfortran-4.
      4 gij-4.
      4 go
      4 gobjc-4.
      4 gobjc++-4.
      4 h
      4 iceweasel-l10n-e
      4 iceweasel-l10n-k
      4 kde-i18n-f
      4 kde-i18n-h
      4 kde-l10n-e
      4 kde-l10n-s
      4 kile-i18n-e
      4 koffice-i18n-e
      4 koffice-i18n-s
      4 koffice-l10n-e
      4 koffice-l10n-f
      4 libqbanking
      4 myspell-f
      4 myspell-h
      4 openoffice.org-help-e
      4 openoffice.org-l10n-b
      4 openoffice.org-l10n-h
      4 openoffice.org-l10n-k
      4 sd
      4 tcl8.
      4 tk8.
      5 aspell-e
      5 aspell-h
      5 iceweasel-l10n-s
      5 kde-i18n-b
      5 kde-i18n-e
      5 kde-i18n-t
      5 kde-l10n-k
      5 openoffice.org-l10n-e
      5 openoffice.org-l10n-t
      5 pa
      5 tc
      6 gc
      6 kde-i18n-s
      6 libdb4.
      6 m
      6 openoffice.org-l10n-n
      6 openoffice.org-l10n-s
      6 s
      7 hbf-cns40-
      9 gp

But there are also some other interesting observations to make:

• OpenOffice.org seems to have by far the biggest number of localisations, with KDE being 2nd.
• There are 6 version of the Berkeley DB in Debian: libdb4.2 to libdb4.7 (including oldstable as mentioned above)

I leave it as an exercise to the reader to find the full names of the other package names starting with s, m, gc, pa or tc and having just one additional character. ;-)

After everybody though that Midnight Commander is dead and the next release of it will be released together with hurd, it is very cool to announce that a new team of developers are active again. We've taken over officially the development in December and now, after two months of work a new version of mc is available: 4.6.2. This is mostly a bugfix release addressing several very nasty bugs which are also present in the debian package. Here the notes what has changed in this release:

• MC Core
  • Changed HQ url to point to new website www.midnight-commander.org (Closes: #137, #138)
  • Added a micro helper library in order to go slowly avay from glib (Closes: #157)
  • Use static strings as section entries in ~/.mc/history WARNING!: This will break old files (Closes: #50)
  • Fixed a repaint issue when clicking on the "View" Button instead of using F3 (Closes: #35)
  • Removed obsolete autoconf macros (Closes: #133)
  • Fix escaping for command line completion (Closes: #147)
  • prevent mc from segfaulting when getting invalid timestamps on files (Closes: #96)
  • Fixed a keybord issue when running mc via a putty console (Closes: #203)
  • setted pty fd to closeonexec (on subshell) (Closes: #174)
  • Fixed file renames, when copying/moving is performed into deleted directories. (Closes: #181)
  • Add an option to show executables first in the panels (Closes: #173)
  • Fixed concatdirand_file if there is a parameter = NULL (Closes: #180)
  • Allow out-of-tree builds (Closes: #224, #208)
• Editor
  • Syntax highlighting for:
    • debian files (debian/changelog, debian/control, debian/copyright, ..) (Closes: #142)
    • updated sh syntax highlighting (Closes: #143)
    • updated pascal syntax highlighting (Closes: #65)
    • differentiate between c and cpp files for highlighting (Closes: #16)
    • updated python highlighting to support python 2.6 (Closes: #216)
  • Removed some unneeded variables (Closes: #168, #151)
  • Do use a ro test if a file exists (Closes: #206)
  • Fixes some missbehaviour in regex matching (Closes: #207, #211 )
    • start at front of line and not on cursor position
    • . shouldn't match a newline
• VFS
  • Fix some bashisms in some extfs scripts (Closes: #146)
  • Fixed various problems with symlinks and files with chars which needs escaping over fish (Closes: #10, #87, #149, #53)
  • Added 7zip extfs descriptor (Closes: #92)
  • Switched from o3totxt to odf2txt as o3totxt is outdated (Closes: #218)
• Locale
  • Updated german translation (Closes: #167)
  • New Belarussian translation (Closes: #170)
  • Updated russian translation (Closes: #159)

As you see.. quite a long list of fixes Have fun and check the new release out right here!

Jeff Bailey writes about the last 26 years of Microsoft [1]. He gives Microsoft credit for “saving us from the TRS 80″, however CP/M-86 was also an option for the OS on the IBM PC [2]. If MS hadn’t produced MS-DOS for a lower price then CP/M would have been used (in those days CP/M and MS-DOS had the same features and essentially the same design). He notes the use of the Terminate and Stay Resident (TSR) [3] programs. As far as I recall the TSR operation was undocumented and was discovered by disassembling DOS (something that the modern MS EULAs forbid). Intel designed the 8086 and 80286 CPUs to permit code written for an 8086 to run unchanged in “protected mode” on an 80286 (as noted in the Wikipedia page about the 80286 [4]). Basically all that you needed to do to write a DOS program with the potential of being run directly in protected mode (or easily ported) was to allocate memory by requesting it from the OS (not just assuming that every address above your heap was available to write on) and by addressing memory only by the segment register returned from the OS when allocating memory (IE not assuming that incrementing a segment register is equivalent to adding 16 to the offset). There were some programs written in such a manner which could run on both DOS and text-mode OS/2 (both 1.x and 2.x), I believe that such programs were linked differently. The term Fat Binary [5] is often used to refer to an executable which has binary code for multiple CPUs (EG PPC and M68K CPUs on the Macintosh), I believe that a similar concept was used for DOS / OS/2 programs but the main code of the application was shared. Also compilers which produce object code which doesn’t do nasty things could have their object code linked to run in protected mode. Some people produced a set of libraries that allowed linking Borland Turbo Pascal code to run as OS/2 16bit text-mode applications. The fact that OS/2 (the protected-mode preemptively multi-tasking DOS) didn’t succeed in the market was largely due to MS. I never used Windows/386 (a version of Windows 2.x) but used Windows 3.0 a lot. Windows 3.0 ran in three modes, “Real Mode” (8086), “Standard Mode” (80286), and “Enhanced Mode” (80386). Real Mode was used for 8086 and 8088 CPUs, for 80286 systems if you needed to run one DOS program (there was no memory for running more than one), and for creating or adjusting the swap-file size for an 80386 system (if your 80386 system didn’t have enough swap you had to shut everything down, start Real Mode, adjust the swap file, and then start it again in Enhanced Mode). Standard Mode was the best mode for running Windows programs (apart from the badly written ones which only ran on Real Mode), but due to the bad practices implemented by almost everyone who wrote DOS programs MS didn’t even try to run DOS programs in 286 protected mode and thus Standard Mode didn’t support DOS programs. Enhanced Mode allowed multitasking DOS programs but as hardly anyone had an 80386 class system at that time it didn’t get much use. It was just before the release of Windows 3.1 that I decided to never again use Windows unless I was paid to do so. I was at a MS presentation about Windows 3.1 and after the marketing stuff they had a technical Q/A session. The questions were generally about how to work around bugs in MS software (mainly Windows 3.0) and the MS people had a very detailed list of work-arounds. Someone asked “why don’t you just fix those bugs” and we were told “it’s easier to teach you how to work around them than to fix them“. I left the presentation before it finished, went straight home and deleted Windows from my computer. I am not going to use software written by people with such a poor attitude if given a choice. After that I ran the DOS multi-tasker DesqView [6] until OS/2 2.0 was released. Desqview allowed multitasking well written DOS programs in real mode, Quarterdeck was the first company to discover that almost 64K of address space could be used above the 1MB boundary from real-mode on a 80286 (a significant benefit when you were limited to 640K of RAM), as well as multitasking less well behaved DOS programs with more memory use on an 80386 or better CPU. OS/2 [7] 2.x was described as “A Better DOS than DOS, a Better Windows than Windows”. That claim seemed accurate to me. I could run DOS VM86 sessions under OS/2 which could do things that even Desqview couldn’t manage (such as having a non-graphical DOS session with 716K of base memory in one window and a graphical DOS session in another). I could also run combinations of Windows programs that could not run under MS Windows (such as badly written windows programs that needed Real Mode as well as programs that needed the amount of memory that only Standard or Enhanced mode could provide). Back to Bill Gates, I recently read a blog post Eight Years of Wrongness [5] which described how Steve Ballmer has failed MS stockholders by his poor management. It seems that he paid more attention to fighting Linux, implementing Digital Restrictions Management (DRM), and generally trying to avoid compatibility with other software than to actually making money. While this could be seen as a tribute to Bill Gates (Steve Ballmer couldn’t do the job as well), I think that Bill would have made the same mistakes for the same reasons. MS has always had a history of treating it’s customers as the enemy. Jeff suggests that we should learn from MS that the freedom to tinker is important as is access to our data. These are good points but another important point is that we need to develop software that does what users want and acts primarily in the best interests of the users. Overall I think that free software is quite well written in regard to acting on behalf of the users. The issue we have is in determining who the “user” is, whether it’s a developer, sys-admin, or someone who wants to just play games and do some word-processing.

• [1] http://jbailey.livejournal.com/55585.html


• [2] http://en.wikipedia.org/wiki/CP/M-86


• [3] http://en.wikipedia.org/wiki/Terminate_and_Stay_Resident


• [4] http://en.wikipedia.org/wiki/80286


• [5] http://msftextrememakeover.blogspot.com/2008/06/eight-years-of-wrongness.html


• [6] http://en.wikipedia.org/wiki/Desqview


• [7] http://en.wikipedia.org/wiki/Os/2

Share This

Continuing from where we left off… The lower bound for me becoming a DD was 8th Feb ‘98 when I applied; for comparison, the upper bound as best I can make out was 23rd Feb, when I would have received this mail through the debian-private list:

Resent-Date: 23 Feb 1998 18:18:57 -0000
From: Martin Schulze 
To: Debian Private 
Subject: New accepted maintainers
Hi folks,
I wish you a pleasant beginning of the week.  Here are the first good
news of the week (probably).
This is the weekly progress report about new-maintainers.  These people
have been accepted as new maintainer for Debian GNU/Linux within the
last week.
[...]
Anthony Towns <ajt@debian.org>
    Anthony is going to package the personal proxy from
    distributed.net - we don't have the source... He may adopt the
    transproxy package, too.
Regards,
        Joey

I never did adopt transproxy – apparently Adam Heath started fixing bugs in it a few days later anyway, and it was later taken over by Bernd Eckenfels (ifconfig upstream!) who’s maintained it ever since. Obviously I did do other things instead, which brings us back to where we left off…

---

• Crypto in main: It’s getting hard to remember the days when strong crypto software was classed as munitions and even getting a web browser to do SSL properly was a legal challenge; but for a long while that’s how it was, and as a result we had to keep all our security tools hosted separately to our main, US-based archive. The laws for that changed in early 2000, introducing a new exemption to the prohibition for software whose source code was available royalty-free (I think they called it “public source”). Unfortunately there were still drawbacks: it wouldn’t apply to some stuff in non-free, it wasn’t clear how far you had to go with the source code (is libssl’s source enough, or do you need the source for the apps that use ssl too?), and the biggest problem was you had to notify the export bureau and the NSA for everything you wanted to distribute. And all of that’s couched in the sort of confusing language you’d expect to find in, well, export regulations. So we ended up getting nowhere on merging crypto into the main archive for a long while because we couldn’t be confident of what we actually needed to do. We’d more or less already missed the opportunity to do the merge for the potato (2.2) release because it was frozen more or less exactly when the new regulations came out, and according to my mail archives Ben Collins (DPL at the time) got a team organised to review the legal issues by mid-May 2001. By July 2001, though, we still weren’t really getting anywhere; the lawyer we were talking to was looking at the ENC exception (which was for closed source stuff, and requires an active review by the BXA), instead of the TSU exception (which just requires notification). While it wasn’t terrible legal advice – following the ENC exception had a lower risk of misunderstandings on our part leading to problems later – it wasn’t useful in achieving our aims, ie, getting crypto stuff into main with a minimal level of ongoing effort, as well as a minimal level of risk. So moving onto August, we’d moved on from the lawyer we’d been using for this and other issues, to talking to a lawyer who specialised in export issues (and whose time was being covered by HP). That actually got us somewhere, with the end results being a matter of public record – we got the advice we wanted by November, we got a new incoming system so we could make sure we didn’t publish anything we hadn’t advised the NSA and BXA about, and most of all, we got cryptographic software in main for woody’s release. ssh at standard priority, apt by default checking archive signatures before downloading code to run as root, iceweasel coping with https:// urls out of the box all suddenly became possible, rather than artificially blocked due to pointless legal constraints. Yay! The way we notified BXA/NSA was somewhat interesting – we ended up notifying once for each package, when it passed through NEW: which is easy to automate, and limits the amount of software we block from review by other developers as best we can. OTOH, it also means a lot of notifications: the initial notification was a huge box of paper that got faxed off (there should be pictures somewhere on the net, but I don’t know where), and the vague hope that the ongoing reporting would not only comply with the regs, but manage to be something of a denial-of-service by compliance. As it turns out it apparently got noticed, with the following mail arriving in September 2005:

  From: Encryption 
  Date: Fri, 23 Sep 2005 12:51:02 -0400
  Subject: Addition to Debian Source Code updates
  Dear Mr. Collins,
  Your diligent reporting of updates to the Debian source code to the Bureau
  of Industry and Security has been an excellent example of perspicacity.
  However, you no longer need to do so per the following update to the EAR:
  [...]
  

  (The mails have always been sent with Ben's name attached) That mail was followed by another suggesting a phone conversation; unfortunately nobody seemed to notice the mail, at least until a year later (to the day!) when Joerg pointed out he was getting bounces form the BXA email address we'd been using... (Since then, based on the above mail, we've been recording notifications, but not passing them on; I sent a reply to the mails above indicating that, but didn't receive a response. There's been about 5000 notifications since then)
• Security and the architecture explosion: with crypto-in-main out of the way, along with lots of RC bug squashing, woody was looking good to come out in April or May, but unfortunately that all fell apart because of a lack of automation for handling security updates. Taking a step back, woody managed to introduce five new architectures compared to the previous release -- HP's pets, hppa and ia64; the IBM mainfram arch, s390, and the SGI/embedded mips and mipsel chips. That came just short of doubling our supported architectures (which had been i386, m68k, alpha, arm, sparc and powerpc), and was working really impressively well: testing was watching that they kept in sync, and the buildd network was keeping them all up to date with the latest source uploads, and the toolchain maintainers were making sure new kernels and compilers didn't cause massive breakages. It was great fun to be a part of, and I'm not sure how much is just blurry memories, but from here, it sure feels like it was a golden age on that score... Anyway, all the extra architectures freaked the security team out, given they were already having to worry about ssh'ing to half a dozen machines and manually do builds, and fix them when they broke, and to deal with that there'd been plans afoot for "rbuilder" to get rolled out, which never actually happened. All of which means it escalated from being the security team's problem, to a problem for everyone, particularly the release manager... The result of which meant knuckling down and coming up with a new security build infrastructure, which involved doing a dak install for the security archive, then building on the changes just rolled out for crypto-in-main to allow for packages to be autobuilt before actually being included in the archive, then updating official buildds for all the various architectures to target stable-security and testing-security and prioritise them and upload to the right place. But as stressful and last minute as that was, at least it worked, and woody made it out the door on July 20th 2002 -- and it's a good thing it worked, given woody ended up getting security support until June 30th 2006 -- the usual year after it's successor is released -- for four years support. (The same rule applied to sarge has resulted in two years and ten months' security support; eighteen month release cycles in general should result in two years and six months of support) Since then, with security managed by dak, there's been a few more bits I've been involved in. The most interesting of which (to my mind) was splitting the security upload queue from being completely secret and restricted to folks who are allowed to access updates prior to public announcement, into separate secret and non-secret queues. That was December 2005, and since then we've gone from having Joey Schulze basically being the sole person doing security updates to two separate teams, with ten new members. It's not without it's problems -- particularly for packages that get (mis)classified as NEW, or that get lost on their way for inclusion in the next stable point update, but it's nevertheless lightyears from where we were in April 2002, or even November 2005.
• Playing other people for suckers: with woody released, the whole "redo to release process" thing was essentially done -- it had been implemented, it had worked all the way to getting a release out, and in a fair few respects had improved things. Instead of the eight months of hand-approved uploads for the potato freeze, things had gone it automatically, albeit with gradually stricter constraints, right up until April; and even when the security problems delayed things, the manual updates only lasted a bit under three months. So at that point I was pretty happy, and looking forward to making things work a bit better and basically passing the buck to someone else. The first bit of buck passing that worked exceptionally well was jumping on Colin Watson, who'd been offering some debbugs patches on IRC, and after a delightfully brief discussion with some of the other debbugs folks, got getting him added to the group and able to make changes directly on the site. His advogato post the next day was:

  Yesterday I was invited onto the group that administers the Debian bug tracking system. I can't decide whether to be intimidated or excited. There's a great deal to do: my first couple of major projects look set to be integrating some of the existing QA interfaces to release-critical bug tracking, and developing a tool to help us edit spam out of bug histories.

  There's a lot to be said for grabbing people at the point where they're still intimidated by what they're joining; sure there's a definite risk that they'll break something you'll have to clean up, but that's pretty easy to deal with, and well worth all the extra excitement and energy that comes with a little bit of nerves. I did a talk on debbugs a few years later, at the 2005 DebConf, at which point we managed to entice Pascal Hakim and Don Armstrong into signing up, if I'm remembering right. At the same time Colin rolled out his implementation of version tracking support for debbugs (which I'd specced up a while ago, and helped design, but cannily avoided actually coding). Shortly after, Pasc put together bug subscriptions, and these days Don's pretty much the primary maintainer of debbugs. How cool is that? Passing on release managership was a bit less fortuitous though; it's a big job, and it's not something that you can offer "patches" for, generally. So after a bit of cogitating on just how to do it, I went with an open recruitment call in March 2003, and then a bunch of practical assignments to get the volunteers used to what RM work actually entailed and to see whether they actually like it. The recruitment call was mostly focussed on all the negatives, half to avoid people volunteering to be RM for the power (to decide which release policy wins, to tell maintainers what to do, to drop packages, or to just decide what name/number the next release gets) instead of wanting to actually do the work to get the next release out and keep developers happy; and the other half was the theory that if you make a job look hard, technical, but not terribly risky, it starts looking interesting to the right kind of people. The assignments generally were two parters -- first to introduce some stuff about release management that they mightn't be familiar with, and the second a bunch of problems that needed resolving that'd use those skills. The first set was RC bug fixing, followed by working out why packages aren't getting into testing, followed by dealing with packages with mutual dependencies and removing packages. At some point that evolved into the testing scripts accepting "hints" from the release team as to what packages to try in combination, or which packages to force out of testing. That turned out pretty successful, with Steve Langasek, Colin Watson and Joey Hess becoming official release assistants in August, and Colin and Steve replacing me as RM in mid-2004. It was also pretty satisfying to see Andi Barth do some more release assistant recruiting in 2005 following much the same model, and indeed using much of my mail verbatim. You can't really ask for better than that, I figure.

Geez, this was meant to be briefer...

I speculate that most of what we do for Debian squares with what others do for their respective distro. Thus, it should be possible to identify a conceptual workflow applicable to all distros, consolidate individual workflows on a per-package basis, and profit from each other. Jonathan let me have the after-afternoon-coffee slot of the Distro Summit for an impromptu discussion on the various workflows used by distros for packaging. The discussion round was very short-notice and despite the announcement sent to the conference mailing list, only ten people showed up: two people familiar with Fedora, and ( versus ) eight Debianites. Regardless, I think the discussion was success- and fruitful. We were able to identify a one-to-one mapping between the Fedora and Debian workflows, even though we use different techniques:

• both distros separate original software ( orig tarball ) from modifications made to fit the software in with the rest of the distro.
• Fedora keeps the .spec file, which references the original tarball, alongside any patch files in a per-release directory in their CVS tree, e.g. /mdadm/fedora8 and /glibc/rawhide. To obtain a source tree, the contributor checks out the CVS subtree, downloads the tarball according to the .spec file, and merges the two. There is a tool to automate this, obviously. This process is regularly executed to produce source RPMs .
• Debian keeps the original tarball next to a diff.gz file on the mirrors, along with a dsc file which refers to them both. Tools like dget take the URL to the dsc file to download all three, then invoke dpkg-source to unpack the tarball and apply the diff. Individual patch files are either stored in ./debian/patches/ (and applied by the diff), or they don t exist (meaning that all modifications are concatenated in the diff.gz file.

Many Debian package maintainers use version control systems to maintain the ./debian directory, and if patch files are stored in ./debian/patches/, then Debian and Fedora both store patch files in a version control repository, which seems awful. Just as I am only one of many who are experimenting with VCS-based workflows for Debian packaging, the Fedora people are also considering the use of version control for packaging. Unlike Fedora, who seem to try to standardise on bzr, I try to cater for the plethora of version control systems in use in Debian, anticipating the impossibility of standardising/converging on a single tool across the entire project. It seems that our two projects are both at the start of a new phase in packaging, a paradigm shift . What better time could there be for us to listen to each other and come up with a workflow that works for both projects? My suggestion currently centres around a common repository for each package across all (participating) distros, and feature branches. Specifically, given an upstream source tree, modifications made during packaging for a given distro fall into four categories:

• upstream changes, such as bug fixes in the original code, or simple things like manpage typos.
• (Linux) distro stuff, such as init.d scripts or Linux-ifications, which upstream doesn t care about or doesn t want.
• .deb/.rpm-specific changes, like the ./debian directory or the .spec file.
• distro-specific modifications, like policy compliance and the like.

Given a version control system with sufficient branching support, I imagine having different namespaces for branches: upstream-patches/*, distro/*, rpm/* or debian/*. Now, when building the Debian package, I d apply upstream-patches/*, distro/*, deb/* and debian/* in order, while my colleague from the Fedora project would apply upstream-patches/*, distro/*, rpm/* and fedora/*, before calling the build tools and uploading the package. There are surely problems to be overcome. Pascal Hakim mentioned patch dependencies, and I can t necessarily say with a clear conscience that my workflow isn t too complicated to be unleashed into the public yet. But if we find a conceptual workflow applicable to more than one distro, it should be possible to implement a higher-level tool to implement it. Also, the above is basically patch maintenance, not the entire workflow. Bug tracking system integration is going to play a role, as well as other aspects of daily distro packaging. I ll leave those for future time. For me, this is the start of a potentially fruitful cooperation and I hope that interested parties from other distros jump on. For now, I suggest my mailing list for discussion. You can also find some links on the Debian wiki.

This is the result of Swiss voting on ISO/IEC DIS 29500, the fast-tracking of the Microsoft Office Open XML file format.

4 screen AG	approval
Accenture AG	approval
ADVIS AG	approval
ALTRAN AG	approval
Baggenstos Wallisellen	approval
Bechtle IT-Systemhaus Thalwil	approval
CIS-Consulting	approval
Comsoft Direct AG	approval
Coris SA	approval
Dr. Pascal Sieber & Partners AG	approval
dynawell ag	approval
Ecma International	approval
ELCA Informatik AG	approval
EPFL Lausanne	disapproval
FSFE Free Software Foundation Europe	disapproval
GARAIO AG	approval
Gysel Ulrich Emanuel	disapproval
H.R. Thomann Consulting	approval
Hewlett-Packard (Schweiz) GmbH	approval
HSW Luzern, Institut IWI	approval
IAMCP Switzerland	approval
IBM (Schweiz)	disapproval
Informatikstrategieorgan Bund ISB	approval
isolutions gmbh	approval
itsystems AG	approval
Kull AG	approval
leanux.ch AG	approval
Leuchter Informatik AG	approval
MESO Products	approval
Microsoft Schweiz GmbH	approval
MondayCoffee AG	approval
Namics AG	approval
NEXPLORE AG	approval
Novell (Schweiz) AG	approval
Online Consulting AG	approval
Open Text	approval
PageUp Bern	approval
PC-WARE Systems (Schweiz) AG	approval
Puzzle ITC GmbH	disapproval
SBS Solutions AG	approval
Secunet SwissIT AG	disapproval
SIUG Swiss Internet User Group	disapproval
SKSF	approval
Skybow AG	approval
SoftwareONE	approval
SyGroup GmbH	disapproval
Sylog Consulting SA	approval
Syndrega	disapproval
TheAlternative	disapproval
Trivadis AG	approval
Unic Internet Solutions	approval
usedSoft AG	approval
Verein /ch/open	disapproval
WAGNER AG Kirchberg	approval
Wilhelm Tux (Verein)	disapproval
Würgler Consulting	disapproval
Zürcher Hochschule der Künste	disapproval
Total of voting (75% majority)	43 approval (75.4%); 14 disapproal (24.6%)

A majority with 75% has been reached with one vote. Why do Hewlett-Packard and Novell vote IN FAVOUR for OOXML!?

Sound Juicer "Nikki's Growing A Patch Out In The Backyard" 2.19.0 is out. Tarballs are available on burtonini.com, or from the GNOME FTP servers. This is the first release in the 2.19.x development series, after I failed to do anything useful in 2.17.x...

• Attempt to repair brain-dead FreeDB encoding (Ka-Hing Cheung)
• Fix memory leaks in musicbrainz object (Cristian Persch)
• Follow the preferred sound device (Bastien Nocera)
• Use xdg-user-dirs (BN)
• Use gst_element_make_from_uri instead of hardcoding cdparanoia (James Livingstone)
• Display a better message after extracting (Adam Petaccia)
• Fix detection of FreeDB albums (David Mandelberg)
• Accessibility fixes (Rich Burridge, Patrick Wade)
• Don't crash if libnautilus-burn doens't know of a device (Pascal Terjan)
• Initialise threading earlier
• Convert strerror() output to UTF-8 for display (PT)
• Remove "Application" category from desktop file
• Fix srcdir!=builddir builds (Loic Minier)
• Internal refactor of extractor and metadata objects

Organisation Like last year, I did not help Pascal to manage the devrooms. I'd like to be more helpfull so as a lot of people I made a little donation and get a FOSDEM2007 t-shirt. The event was even better than last year (even if I think it's also cool last year except the wifi was not working last year). This is the first time since 2004 that I don't meet Wouter! I hope we'll meet next Debian or FOSDEM meeting. Women Is it me or are there more and more women involved in open source? This is one of the great news form this year. read more

I recently came across two old and unrelated writings about law, both of which are worth reading, especially for people with strong opinions but no formal training. The first is this piece, entitled Seven Ways in Which Code Equals Law (And One in Which It Does Not), by recently-appointed New York Law School professor James Grimmelmann and EFF Legal Director Cindy Cohn. Several observations are particularly appropriate for the slashdot crowd (and, to a lesser extent, certain members of the Debian community and others who grew up on a diet of BASIC, Pascal, and then C and later perl). I especially like this bit about “hacking the law”:

Some people, seeing this connection, and remembering the values of good code, try to improve the legal system by treating it as a computer. People come to me with ideas for hacking the law. The government says that cryptography is a weapon, they say, but the Bill of Rights says we have the right to bear arms. So that means we have a Constitutional right to use cryptography. But the legal system isn t a computer. If you can t convince a judge that what you re proposing is consistent with the values underlying a law, your argument will go nowhere. People go to jail every year because they think they ve found a way to hack the Sixteenth Amendment. The income tax is illegal, they say, or, The income tax is voluntary, see, it says so right here, and then they get convicted of tax evasion and sent to jail. We did convince several judges about the Constitutional dimension of cryptography, but the claim started from the values of the First Amendment, not a mechanical reading of its words. It s a category mistake to treat the legal system as just another architecture with its own specialized language. Code and law are different ways of regulating; they have different textures. All of those people who are required to make the legal system work leave their mark on its outcomes: they make a certain amount of drift and discretion almost inevitable. Code doesn t have such a limit: it can make perfectly hard-nosed bright-line rules and hold everyone in the world to them. Code is capable of a kind of regulatory clarity and intensity that law can only state, never really achieve.

I don’t entirely agree with the other article, entitled What I Ate For Breakfast and Other Mysteries of Judicial Decision Making by outspoken Ninth Circuit Judge Alex Kozinski (unofficial site maintained by Aaron Swartz, wikipedia entry). For example, I think critical legal studies has resulted in some interesting insights, some of which actually have practical applciation. Still, Judge Kozinski makes an important point about the numerous factors that act as a check on discretion in judicial decisionmaking:

It is popular in some circles to suppose that judicial decision making can be explained largely by frivolous factors, perhaps for example the relationship between what judges eat and what they decide. Answering questions about such relationships is quite simple - it is like being asked to write a scholarly essay on the snakes of Ireland: There are none. But as far back as I can remember in law school, the notion was advanced with some vigor that judicial decision making is a farce. Under this theory, what judges do is glance at a case and decide who should win - and they do this on the basis of their digestion (or how they slept the night before or some other variety of personal factors). If the judge has a good breakfast and a good night’s sleep, he might feel lenient and jolly, and sympathize with the downtrodden. If he had indigestion or a bad night’s sleep, he might be a grouch and take it out on the litigants. Of course, even judges can’t make both sides lose; I know, I’ve tried. So a grouchy mood, the theory went, is likely to cause the judge to take it out on the litigant he least identifies with, usually the guy who got run over by the railroad or is being foreclosed on by the bank. This theory immodestly called itself Legal Realism. Just to prove that even the silliest idea can be pursued to its illogical conclusion, Legal Realism spawned Critical Legal Studies. As I understand this so-called theory, the notion is that because legal rules don’t mean much anyway, and judges can reach any result they wish by invoking the right incantation, they should engraft their own political philosophy onto the decision-making process and use their power to change the way our society works. So, if you accept that what a judge has for breakfast affects his decisions that day, judges should be encouraged to have a consistent diet so their decisions will consistently favor one set of litigants over the other. I am here to tell you that this is all horse manure. And, like all horse manure, it contains little seeds of truth from which tiny birds can take intellectual nourishment. The little truths are these: Under our law judges do in fact have considerable discretion in certain of their decisions: making findings of fact, interpreting language in the Constitution, statutes and regulations; determining whether officials of the executive branch have abused their discretion; and, fashioning remedies for violations of the law, including fairly sweeping powers to grant injunctive relief. The larger reality, however, is that judges exercise their powers subject to very significant constraints. They simply can’t do anything they well please.

Finally, I will link, but not embed, this video of the Anna Nicole Smith court order, for an entirely different perspective on the legal process. You almost don’t really want to have to see this stuff.

A few month ago, I blogged a way to spread Free Software effectively, especially in developing countries: By deploying Free Software in internet caf s, where most people learn their way around computers. Most of them (and there are a lot, much more than in Europe) have a buisness plan that relies on software for free, but currently they achieve that through pirating Windows and software like Cybercafe Pro. Back than, I wrote this more or less theoretically, but it happend that I ended up having some time to actually start working on it.While Free Software, especially Debian, provides a very good base to build internet caf s from, one key component is more or less missing: Software to hand out these codes ( timecodes ) to the customer, to let them log in and surf for the time they bought. Very recently, Zybacafe was released, but I did not really like it, nor felt like maintaining a Pascal/Lazarus based Debian package. So I went ahead and implemented my own ideas.The Idea is to keep it very simple, very modularized and integrate deeply with normal unix ideas. So what we have now is a PostgreSQL database (one table so far), and all communication just goes via this table, so we don t have to design or implement complicated protocols. A python gtk application for the front desk generates the timecodes that are then, on paper, passed to the customer. The workstations greet the user with standard GDM, but our pam modules authenticates the timecode instead of a username/password pair. While using the system, a small floating window informs the user about the remaining time. If he does not log out voluntarily, a system daemon will kill all his processes eventually.The long term mission is to form that into a Custom Debian Distribution that will install the server hassle-less, and besides being pre-configured for the internet caf s needs, also immediately serves as an automated installation server for the workstations (think FAI), all useing stock Debian packages, as far as possible. Another pam module could, upon login, mount the homedirectory as a copy-on-write overlay of a template user s home directory, and through away the changes afterwards. The goal is to offer easier installation, less maintenance, better robustness and more flexibility than the current common non-free systems.But, of course, this project needs help. First of all: Users! If you have any use for time-limited logins (Internet caf , school surf terminaly, parents with otherwise not to bed going kids), you can be an earliy adaptor. Developers are very welcome as well, and due to the modular structure, cooperation should be quite smooth.The development happens on alioth, where we have the subversion repositry, as well as on the Debian wiki page. Alpha packages for these components can be found on the alioth group s webspace. We do not have a mailing list yet, but feel free to e-mail me. We will set up a mailing list once there is a need for it. Thank s to the KACE for supporting this.

Last week Pascal, who is a friend of bubulle, asked me how he could make ISO image with kernel 2.6.18 for Sarge. Timely I'd like to have a kernel 2.6.18 image for myself also (I bought Core2Duo machine. It has VIA VT8237A SATA controller isn't supported before 2.6.18), I made it. You can take it from the usual place; sarge-custom-1008.iso for i386.

• Backported 2.6.18 kernel from unstable.
• LVM/RAID will *NOT* work. Maybe I have to backport partman and dmraid to support them, but I haven't done yet.
• Since kernel 2.6.17, Debian kernel team merged SMP support to a single kernel. So don't panic even -smp kernel isn't installed. ISO image has -486, -686, -686-bigmem, and -k7.
• I haven't AHCI machine and I don't know PATA CD vs SATA HD problem still happen on 2.6.18. But I add a feature "atapi=true" boot option. When you append this option as the boot parameter, the installer will add the configuration to /etc/modprobe.conf.

One of the things I've been working on, on and off for the last few months is teams.debian.net. Along with a few others, we felt that there were not enough options for Debian-related mailing list hosting. While this may seem strange to some, a number of people at DebConf5 found the idea to be worthwhile. Most Debian-related lists which would not be considered for lists.debian.org could find hosting at teams.debian.net instead. The main purposes behind teams.debian.net are:

• Test bed for new software/methods that can then be deployed to lists.debian.org. In particular, we'd like to see EoC which would provide us with a few advantages over Smartlist which is currently in use on lists.debian.org.
• the ability to have temporary mailing lists
• Mailing list hosting for local Debian user groups
• Mailing list hosting for Debian related events and sub-events

To request a new mailing list, simply follow the instructions on teams.debian.net Of course, like any free software project, there are still some things which are needed. The main one is currently the lack of a public web archive for lists which want it. I wanted to try to replace MHonArc with something that looked a little better and was more user-friendly, but I have yet to find something which I think would be an appropriate replacement. While some have suggested Lurker, I feel that is not very useable in a long term hosting environment, as it is harder to navigate around older entries. While this is acceptable in some places, it's definitely not in others. You can consider a "Dear Lazyweb" paragraph if you wish. Many thanks to Andreas Barth and Martin Zobel-Helas for their help in setting this up, providing machine space, and prodding me along when necessary.

After the DzongkhaLnux launch event which I already blogged about as well as published a report in debian-devel-announce, I got interviewed by Computerworld.au. They turned this interview into one of their head stories, which IMHO gives Debian an interesting exposure. Moreover, I am very happy of the way they wrote the story, which gives Debian the credit it deserves in that story and gives a very good transcription of my own ideas about free software. It also puts yet more exposure on the Bhutanese authorities initiative and I think they really deserve it as well. Thanks indeed to Pascal Hakim who made this possible and to Dahna McConnachie who wrote the news entry and conducted the interview.

A friend of mine with a 10 year old child wants his son to play less online Role Playing games and learn programming. In this kid’s free time, all he does is play computer games. At that age I was probably the same, though what made me a “programmer”? My friend is so frustrated with his son’s constant game playing, that he has limited his son to use the computer only in the weekends. I found this quite surprising, but I think I can understand his concern. I remember not coming down for dinner, because I wanted to play BRE (BBS door games) with my friends instead. Thankfully my Dad never threw out my computer out the window like he swore he would do at times. :) So now, my friend suggests that perhaps we could teach his child something about programming. Perhaps a whole group of kids. All armed with laptops. But, when I was that age, I don’t think I was very interested in programming for the most part. I had to be forced to write some logo and turbo pascal for school. And looking back at it, logo and turbo pascal seemed so much easier than the complex and multi-layered APIs (Web) I work with everyday. Ok, I do remember being enthused about:

• demoscene
• LAN parties with doom2 and quake

But both of these cultures seem to be on the decline. Or perhaps I am just out of touch? During boarding school I actually stopped having access to BBS/Internet so I didn’t really touch a computer throughout my A-levels. It was only at Bath University where I found myself, almost surprisingly, taking a Computer Science course I learnt about Unix et al. So I started learning Computer Science at University. I think people in Korea are surprised when I tell them I hardly knew about computers before I joined a Computer Science course! ;) Ok, so without driveling any more. Here are the questions for you to say your bit in the comments.

• Do you think it is worthwhile to teach programming (Computer Science) to a child?
• How can we get kids more excited / creative about computer science?
• And how should a parent deal with computer game addicted kid?

It would be great to teach on Plan9 or something simple, but I think kids would be more interested in graphics and sound. Bleh…

I was not a part of the devrooms team this year (like the last two years), Pascal did all the job! I was just a simple visitor and it’s a very cool position. Mark already bloged about the Classpath’s presentations, so you can find some interresting slides there. Saturday (25th February 2006) RMS Excellent talk about the patent. As always, Richard Stallman has great images to explain complex things. I still can’t understand all the GPL3 changes but I’ll try to read some more articles about it. Putting ‘Free’ into JFreeChart The presentation from David Gilbert was very cool. I did not know JFreeChart and it is really cool! This is a very big project and it makes very beautiful charts. I’d like to find some charts to do just to use it! Eclipse for GNU Classpath Development Tom Tromey did a fantastic presentation again. I already saw his presentations past years and it was still excellent. He already tried to explain me how to set up this Eclipse/GNU Classpath setup on IRC but I missed the “Don’t build automatically” hack. Everything should be on the Classpath’s wiki. Xen A presentation by Ian Pratt, leader of the Xen Source project. I heard about this project but I didn’t know that you could move an instance from a machine to another one! Amazing! Sunday (26th February 2006) I met Wouter in the bus but he lost his voice and asked me to introduce the speakers of the Debian room. I’m sorry for the three speakers I announced if it was not just as good as if Wouter did it. I wanna intend to the two conferences anyway. Women in Free Software I already wanna be at the talk of last year but I was in the Classpath devroom. Hanna M Wallach did a fantastic talk. I learned a lot of things and I know now that there really is a need of the debian-women project. I proposed her to put a phrase or a logo or something on the Debian-Java projects web pages and she seems to be pleased. Tonight, I went on #debian-women and it seems I did not understand nothing . So maybe I’d better do nothing about this unless I understand what I could do to help. Debian GNU/kFreeBSD port After the talk of Hanna, I introduced the kFreeBSD talk of Aurelien Jarno. I wanna listen to this talk because I completely don’t know *BSD… I’m sorry but I don’t know more. And I still don’t know the difference with Linux and don’t know why I should, as a simple user change to some *BSD port? Debian-Java Meeting After the kFreeBSD talk, I introduced the SLIND talk in the Debian Room, told Wouter that I go to the Classpath Devroom… and listen to the end of the talk of Christian Thalinger (CacaoJVM — the site was down when I tried). Sorry Christian, I just don’t understant these thing During the talk (or was this just after the talk of Robert about JamVM?), I went eating with Wolfgang Baer. We went back during the Christian’s talk. Then we had a Debian-Java talk (I should be writing down the summary of this meeting instead of blogging)… I’ll send an email about the meeting, don’t worry Future of Classpath It is the time when Mark ask everybody: What do you do? How can we help you? It’s a great social/technical time when everybody listen carrefully to everybody. It’s wonderful. Maybe it’s the part I prefer in free software. I must say that I read some mailing lists before joining some project and the ‘Classpath’ (and friends) projects were the one I prefer because of that respect. Then came the camera… A team came in the room to film us. They claim they were making a movie about Free Software. Funny I discussed a little bit with the woman that seems to be the director and she asked for my email (no, Hanna, it was not because she felt I am sexy , nobody tells me 100 times I’m sexy ). I told her I was not one of the main contributor but she just wanna talk about free software and understand how it works. Closing Talk: The Challenge of the GNU/Linux Desktop by Jeff Waugh Jeff Waugh is an excellent speaker, I really enjoyed the presentation. A lot of humour, a lot of facts, it was really an excellent presentation. But Jeff, I still do not understand the Ubuntu business plan. I’m not a native english speaker and I did not understand a lot of jokes and some responses. Back! I messed up with my GSM, lost my PIN number or someting I don’t know (I did it a thousand times!), I went to the shop today (Feb. 28) to be able to call again. I also went to the office and the alarm was on… I asked for the security guard (I did not want to take risks the day of my birthday: February 28th)… we found nobody but someone tryied to enter on Sunday. I’ll try to prepare some report about Debian-Java tomorrow. The report will be reviewed by Wolfgang and Michael and I’ll send it on the debian-java list on Saturday or on Sunday.

I never thought I would see the day where I would actually find a vacuum cleaner cool. So... Who's going to be the first to put Debian on it?

So I got pet peeved by Carlos Laviola in relation to by recent pondering about how MacOS X's SSH agent starts up on login. Perfectly reasonable grounds for complaint. I have had people contact me in relation to blog posts in the past, so it's obviously not impossible. People know I'm a Debian developer and can put two and two together and wind up at db.debian.org. Anyway, I'm the first to admit that my blog probably has too many of the Weblog Usability Top Ten Design Mistakes (something for me to work on). To date, I've been avoiding plastering my email address on my website because I didn't want to get it harvested. I try and use a per-list email address for this reason as well, and I haven't enabled blog comments because of comment spam, and because I haven't been clever enough to implement comments with Blosxom full stop. So I started getting an idea for reversibly encrypting my email address on my blog after reading about Hashcash for Wordpress the other day. I first started playing around with the Vernam cipher in High School, when I wanted to easily reversibly obfuscate some data for something. I'd read about this cipher in a magazine or something and seen it implemented in Pascal (it's not exactly hard). So I happened upon the idea of encrypting my email address with the Vernam cipher. Turns out another chap's already got a page for encrypting and decrypting on the fly with JavaScript. It even generates the JavaScript for putting in your own web pages. I had to use a different key to avoid getting dollar signs in the encrypted string, as this confused the tripe out of Blosxom (and me for a while when I tried to figure out what was going wrong). Then I thought it'd be nice to explain to people who had JavaScript disabled what they might be missing out on, so I fiddled around with some DOM stuff, and had some text get displayed if JavaScript was disabled. When JavaScript is enabled, this text is replaced by the decrypted text. So of course, like the Wordpress Hashcash, this is largely relying on the inability of spam bots to grok JavaScript. Once they can, this obfuscation technique is all for naught. Meanwhile, you can email me bit more easily now if you get the urge. View the source of my blog for an example of the implementation.

Finally, I can drop freepascal. It turned out to be far more effective to rewrite things in c++ (like, do a module in a day, while I've been fighting freepascal for a week, before I worked around all quirks and bugs). Maybe life does not suck that much, after all...